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Abstract:  The  proof  rules  of  Euclid,  like  the  axiomatization  of  Pascal,  presents  a 
single  definition  of  the  various  features  of  the  language  being  defined.  Little 
effort  is  made  to  explain  the  proof  rules  or  to  compare  them  to  alternatives.  In 
this  paper  we  take  one  of  our  more  complex  proof  rules,  the  rule  for  procedure 
definition  and  call,  and  attempt  both  to  explain  its  workings  and  to  compare  it  to 
two  alternative  rules.  The  rules  we  have  chosen  for  comparison  are  Hoare’s 
adaptation  rule,  from  which  our  rule  is  derived,  and  the  Pascal  procedure-call 
rule. 


Introduction  and  notation 


An  overriding  goal  in  the  design  of  Euclid  [Lampson77,  Popek77]  was  that  Euclid  programs 
be  formally  verifiable.  While  designing  the  language,  it  was  therefore  necessary  to  devote 
attention  to  the  form  its  proof  rules  [London77]  might  take.  In  light  of  the  difficulties  encountered 
in  writing  proof  rules  for  the  procedure-call  mechanisms  of  other  languages,  special  attention  was 
devoted  to  the  design  of  this  aspect  of  Euclid.  In  particular,  the  language  was  designed  with  the 
intent  of  using  a rule  similar  to  Hoare's  rule  of  adaptation  [Hoare71]  as  implemented  in 
[tgarashi75} 
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A key  feature  in  the  language  design  was  the  elimination  of  all  aliasing.  This  allowed  us  to 
meet  our  design  goal  of  relaxing  the  adaptation  rule’s  proscription  of  global  variables.  The 
explicit  appearance  in  the  procedure  heading  of  a list  of  all  global  variables  imported  into  (i.e., 
used  by)  the  procedure  made  it  easier  for  us  to  deal  with  the  "implicit  parameters"  discussed  in 
the  axiomatization  of  Pascal  [Hoare73],  a language  to  which  the  designers  of  Euclid  owe  a heavy 
debt. 

Our  notation  for  expressing  proof  rules  is  derived  largely  from  that  of  [Hoare73].  P(y/x), 
which  may  be  read  "P  with  y for  x,"  denotes  the  formula  obtained  by  systematically  substituting  y 
(or  all  free  occurrences  of  x in  the  predicate  P.  If  a conflict  between  free  variables  of  y and 
cound  variables  of  P is  introduced,  it  is  resolved  by  a systematic  change  of  the  latter  variables. 
The  notation 

V n/*n> 

denotes  simultaneous  substitution  for  all  occurrences  of  any  x;  by  the  corresponding  y^ 
occurrences  of  x,  within  any  yj  are  not  replaced.  The  expressions  Xj,  . . xn  must  be  distinct; 
otherwise  the  simultaneous  substitution  is  not  defined. 

Additional  notation  is  needed  to  define  substitution  for  an  array  reference.  Borrowing  from 
[McCarthy63],  we  use  assign(x,i,y),  where  x is  an  array  identifier,  to  stand  for  the  array  x with  the 
element  x(i)  replaced  by  y.  The  formula 

P(y/x(i», 

denoting  a substitution  for  an  array  reference,  is  then  defined  to  be 

P(assign(x,  i,  y)/x). 

To  extend  this  definition  to  the  substitution  for  a multiply-subscripted  array  reference,  we  define 

assignfx,  <ij, . . in>,  y),  where  n>2 

to  be  equal  to 

assignfx,  <ij, . . in_j>,  assignfx,  in,  '/)) 

and  the  formula 

P(y/x(ij) . . . <in>),  where  n >2 

as  equivalent  to 

P(assign(x,  <ij, . . in>,  y)/x). 

Substitution  for  a record  field  reference  is  defined  analogously;  for  dereferenced  pointer 
variables  the  identity  pt  - C(p)  is  used  where  C is  the  collection  associated  with  p. 
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The  components  of  a Euclid  procedure  declaration  are  given  by  the  schema* 

procedure  p(var  x,  nonvar  c)  imports  (var  y,  nonvar  d)  - 
pre  P;  post  Q;  begin  S end. 

Basic  symbols  ("reserved  words")  of  Euclid  are  underlined.  Nonvar  denotes  the  list  of  const  and 
readonly  identifiers.^  The  procedure  named  p is  declared  with  explicit  formal  parameters  x and  c, 
imported  identifiers  y and  d,  and  body  S.  Associated  with  each  formal  parameter  declared  in  the 
procedure  heading  is  its  type.  From  the  heading,  we  may,  therefore,  generate  an  assertion  of  the 
form 


x i type  of  x a c < type  of  c. 

We  will  call  this  assertion  H.  Similar  assertions  for  y and  d are  provided  by  the  proof  rules  for 
declarations.  P,  the  precondition  for  p,  is  a predicate  involving  x,  c,  y,  and  d;  it  gives  the  only 
relation  among  those  four  identifiers  that  may  be  assumed  by  S.  Q is  the  postcondition,  or 
specification  of  the  result,  of  p.  In  addition  to  x,  c,  y,  and  d,  Q may  involve  x’  and  y\  fresh 
variables  which  denote  the  initial  values  of  x and  y at  entry  to  S. 

The  basic  proof  rule  defining  a procedure  call  p(a,  e)  with  actual  parameters  a and  e 
corresponding  to  the  formal  parameters  x and  c is 

H I—  x-x’  a y-y’  a P { S } Q 


P(a/x,  e/c)  a (Q(a*/x,  e/c,  ya/y,  a/x\  y/y')  o R(a*/a,  y»/y))  { p(a,  e)  } R 

The  premise  of  this  proof  rule  simply  requires  that  H |~  P { S ) Q be  shown—that  is,  in  terms  of 
formal  parameters,  assume  P and  show,  using  all  of  the  Euclid  proof  rules  and  the  assertion  H,  that 
the  execution  of  S will  yield  Q.  P { S } Q need  be  shown  only  once  for  each  procedure 
declaration,  not  once  for  each  call,  because  the  rule  "adapts"  this  single  proof  to  every  call  (hence 
the  name  adaptation).  The  other  two  terms  of  the  premise  merely  define  the  prime  notation. 

The  conclusion  of  this  proof  rule  states  that  it  is  sufficient  for  the  predicate  of  the  form 
P a (Q  a R)  to  hold  prior  to  the  call  of  p(a,  e),  if  the  predicate  R is  to  hold  after  the  call  (like  the 
assignment  axiom,  though  with  quite  different  details).  The  term  P in  P a (Q  a R)  states  that  the 
actual  parameters  satisfy  the  precondition  P of  p,  thereby  discharging  the  assumption  of  P in  the 
premise.  The  term  Q o R states  that  Q may  be  used  in  proving  (the  substituted)  R.  The 
simultaneous  substitutions  into  P and  Q are  clearly  well-defined  because  the  formal  parameters  x, 
c,  and  y (and  x’  and  y’)  are  distinct.  The  substitution  into  R is  well-defined  because  Euclid 
contains  the  restriction  that  all  of  the  var  parameters  a and  the  imported  var  variables  y of  a call 
are  distinct,  i.e.,  non-overlapping.  The  latter  restriction,  which  we  will  call  the  no-aliasinp. 
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One  may  view  x,  c,  y,  and  d as  single  variables  or  as  lists  (vectors)  of  variables;  in  either 


case  the  type  information  of  the  variables  is  omitted. 
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No  assignments  may  be  made  to  these  identifiers  within  the  procedure  p. 
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restriction,  is  a generalization  of  an  adaptation  rule  restriction  and  exists  in  part  to  satisfy  this 
proof  rule. 

To  see  how  information  after  the  call— namely  Q and  R— is  carried  back  across  the  calf  of  p, 
it  is  necessary  to  look  at  the  substitutions  in  more  detail.  The  symbol  indicates  that  the 
variables  a and  y (in  Q and  R)  must  be  replaced  by  fresh  variables.  This  is  necessary  because  the 
names  a and  y in  P a (Q  o R)  refer,  as  always,  to  values  before  the  call  of  p.  New  variables  must 
be  invented  for  a and  y that  will  refer  (before  the  call)  to  the  changed  values  of  these  variables 
after  the  call.  No  other  variables  need  be  invented,  because  only  a and  y can  be  changed  by  p. 
The  purpose  of  the  substitutions  can  now  be  seen  as  the  replacement  of  formal  by  actual 
parameters  and  as  the  introduction  of  fresh  variables  for  the  actuals  a and  y.  The  substitutions  of 
a for  x*  and  y for  y’  reflecf  the  fact  f hat  a and  y are  the  initial  values  of  the  actual  parameters 
and  should  replace  x'  and  y\  While  both  the  prime  notation  and  the  *s  are  used  to  refer  at  a 
point  to  values  of  variables  not  available  at  the  point,  they  are  different  in  two  respects.  First, 
primes  involve  formal  parameters  and  *s  involve  actual  parameters,  and  second,  primes  denote 
initial  values  and  as  denote  final  values. 

It  should  be  noted  that  if  two  or  more  of  the  actuals,  a,  are  components  of  the  same  array,  a 
slight  complication  arises  in  substituting  for  the  actuals.  R(a*/a,  y»/y)  may  evaluate  to  a formula 
of  the  form 

R(al»/B(ij)  . . . <im),  a2*/B(jj)  . . . <jn». 

Since  the  no-aliasing  restriction  guarantees  that  there  exists  a k where  1 Sk<m<n  such  that 
'k  ^ ik*  substitution  is  well-defined.  Applying  the  rule  for  array  element  substitution  will 
reduce  this  to 

R(assign(B,  <ij, . . .,  im>,  al«)/B,  assign(B,  <jj, . . .,  jn>,  a2*)/B). 

At  this  point  simultaneous  substitution  is  no  longer  well-defined.  We  therefore  define  extended 
simultaneous  substitution  with  the  rule 

R(assign(8,  <ij, . . .,  im>,  al»)/B,  assign(B,  <jj, . . .,  jn>,  a2«)/B)  - 
R(assign(assign(B,  <ij, . . .,  im>,  al*),  <jj, . . .,  jn>,  a2*)/B). 

Note  that  in  verifying  Euclid  programs  this  situation  can  only  arise  in  connection  with 
substitutions  generated  by  application  of  the  procedure-call  rule.  In  this  environment,  we  know, 
by  the  no-aliasing  restriction,  that  replacing  the  simultaneous  substitutions  with  what  is  in  effect  a 
sequential  substitution  involves  no  information  loss.  Consider,  for  example,  the  substitution 

P(x/A(iXj),  y/A(kXmXn)). 

It  first  reduces  to 

P(assign(A,  <i,  j>,  x)/A,  assign(A,  <k,  m,  n>,  y)/A) 
and  then  (by  extended  simultaneous  substitution)  to 


I 


PROOF  RULE  FOR  EUCLID  PROCEDURES 


5 


P(assign(assign(A,  <i,  j>,  x),  <k,  m,  n>,  y)/A). 

Since  we  know  that  either  i y k or  j y m,  we  know  that  the  outer  assignment  will  not  obliterate 
any  of  the  values  imparted  by  the  inner  assignment.  Without  the  no-aliasing  restriction,  this  might 
not  be  the  case.  Whether  with  aliasing  the  resulting  substitution  accurately  mirrors  the  effect  of 
the  procedure  depends  upon  the  order  in  which  the  formals  are  assigned  to  in  the  procedure. 
The  problem  is  that  an  assignment  to  one  formal  may  overwrite  a previous  assignment  to  a 
different  formal.  The  sequential  substitution  defined  by  "assign"  may  coincidentally  reflect  this 
correctly,  but  there  is  no  way  to  ensure  this. 

The  above  basic  proof  rule  is  still  missing  two  features  of  Euclid  procedures.  The  first  is  a 
return  statement  with  the  informal  meaning  that  control  should  return  immediately  from  the 
procedure  currently  being  executed.  The  proof  rule  for  return  is  merely  the  statement  that  the 
axiom 


Q { return  } false 

may  be  used  in  showing  P { S } Q for  p.  The  rule  is  expressed  by  adding  this  axiom  to  the 
premise  to  the  left  of  the  |--.  The  Q in  the  axiom  is  the  postcondition  Q of  p.  The  form  of  this 
axiom  should  be  compared  to  the  .go  to  axiom 

assertion  at  L { go  to  L } false 

where  L is  the  end  of  the  procedure.  Q is  the  "assertion  at  'the  end’"  and  return  means  go  to_"the 
end."  Note  that  the  axiom  Q ( return  } false  is  not  sound  if  there  is  a module  variable  instantiated 
in  the  procedure  p.  In  this  case  some  "finalization"  code  may  be  executed  before  exiting  the 
procedure.  This  code  might  falsify  Q. 

The  second  missing  feature  is  recursion.  As  with  Hoare’s  presentation  of  the  adaptation 
rule,  the  rule  above  will  fail  if  p is  called  recursively,  for  there  is  then  no  way  to  show  the 
premise  term  P { S ) Q.  The  solution  is  identical  to  Hoare’s:  invoke  the  rule  "recursively"  (or 
"inductively  on  the  depth  of  recursion")  by  adding  to  the  premise  to  the  left  of  the  turnstile  a 
copy  of  the  rule’s  conclusion,  which  indicates  that  the  rule  itself  may  be  used  on  all  recursive  calls 
in  showing  P { S } Q. 

The  proof  rule  that  includes  recursion  and  returns  is,  therefore, 

[ P(al/x,  el/c)  a (Q(al*/x,  el/c,  y*/y,  al/x’,  y/y’)  =>  Rl(al*/al,  y*/y))  { p(al,  el)  } Rl, 

Q { return  } false,  H ] |— 

x=x’  A y=y’  A P { S } Q 

• 

P(a/x,  e/c)  a (Q(a»/x,  e/c,  y*/y,  a/x\  y/y’)  3 R(a*/a,  y«/y))  { p(a,  e)  } R 

In  the  recursion  clause  Rl  replaces  R,  and  al  and  el  replace  a and  e to  allow  different  predicates 
and  different  actual  parameters  to  be  used  in  recursive  calls. 

Earlier  we  noted  that  Euclid  requires  of  a procedure  call  that  all  of  the  actual  var 
parameters  and  imported  var  variables  be  distinct.  In  the  absence  of  var  subscript  expressions 
(and  var  dereferenced  pointers),  the  restriction  is  easy  to  enforce  because  a simple  equality  check 
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of  variable  namet  suffices.  As  we  have  already  pointed  out,  however,  with  var  subscript 
expressions  or  var  dereferenced  pointers  the  equality  check  must  involve  values.  Thus,  to 
enforce  the  restrictions  on  procedure  calls,  it  is  necessary  to  show  that  certain  values  are  distinct. 
In  Euclid  this  responsibility  is  placed  on  the  compiler;  if  it  cannot  succeed  by  itself,  the  compiler 
generates  legality  assertions  sufficient  to  show  that  the  variables  are  distinct.  For  the  procedure 
call  p(A(i)(j),  A(k)(m)(n)),  where  both  parameters  are  var.  the  legality  assertion  would  be 

i i k v j + m. 

In  addition  to  showing  all  other  assertions,  the  verifier  of  a Euclid  program  must  prove  that  each 
legality  assertion  holds  at  the  point  of  call. 


Comparison  with  other  procedure  rules 


If  we  ignore  the  recursion  clause,  Hoare’s  adaptation  rule  may  be  expressed  as 

P l S }Q 


P(a/x,  e/c)  a Va(Q(a/x,  e/c)  o R)  { p(a,  e)  } R 

Imported  variables  are  forbidden  in  this  rule.  A minor  difference  in  this  rule  and  ours  is  our 
explicit  use  of  the  prime  notation  for  initial  values.  Any  other  consistent  notation  will  suffice, 
including  keeping  it  implicit  (as  here)  as  part  of  the  notation  for  the  pre-  and  postconditions.  An 
important  difference,  however,  is  the  method  of  renaming  variables,  which  Hoare's  rule 
accomplishes  by  the  for-all  quantifier  on  the  variable  a (this  is  the  sole  purpose  of  the  quantifier). 
One  of  the  restrictions  in  using  this  adaptation  tule  is  that  no  actual  var  parameter  may  appear  in 
a const  parameter,  which  is  consistent  with  the  fact  that  the  scope  of  the  quantifier  is  over  all  of 
the  term  Q o R;  thus,  if  a var  parameter  violated  the  restriction,  it  would  be  renamed  incorrectly 
by  the  quantifier.  Our  proof  rule,  on  the  other  hand,  removes  this  restriction  by  a more  selective 
renaming  of  variables  in  the  term  Q a R. 

In  place  of  P a (Q  3 R)  in  either  procedure-call  rule,  it  is  possible  to  have  instead 

(P  3 Q)  d R as  is  done  in  [Morris71].  The  latter  precondition  is  weaker  than  the  former  (they 

differ  when  P is  false  and  R is  true,  i.e.,  when  R can  be  proved  without  the  help  of  Q).  In  Euclid 
we  have  adopted  the  language  design  decision  that  the  meaning  of  a procedure  is  undefined  if  its 
precondition  does  not  hold  at  the  point  of  call.  Under  this  assumption  (P  3 Q)  3 R becomes 
P a <(P  3 Q)  3 R),  which  is  equivalent  to  P a (Q  3 R).  We  believe  this  to  be  a cautious  and 
convenient  choice.  However,  by  a suitable  selection  of  pre-  and  postconditions,  we  can  show  that 
there  is  no  loss  of  generality:  It  is  always  possible  to  choose  the  precondition  to  be  the  constant 
true,  which  always  holds,  and  to  choose  the  postcondition  to  be  P 3 Q where  initial  and  final 

values  must  be  carefully  written  in  P.  The  nontrivial  precondition  has  been  moved  into  the 

postcondition. 

Our  procedure  rule  is  also  different  from  the  treatment  in  [Hoare73],  which  uses  two  rules: 
one  for  procedure  declarations  and  one  for  calls.  In  addition  to  the  general  postcondition  0,  the 
declaration  rule  also  uses  functions  f(x,  c,  y,  d)  and  g(x,  c,  y,  d)  which  map  the  initial  values  of  the 
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formal  parameters  and  imported  identifiers  x,  r,  y,  and  d onto  the  final  values  x and  y after  the 
completion  of  S.  The  functions  f and  g are  defined  by  the  statement  that  we  may  deduce  the 
existence  of  f and  g,  satisfying  the  implication 

P ^ Q(f(x,  c,  y,  d)/xt  g(x,  c,  y,  d)/y) 

for  ail  values  of  the  variables  involved.  Informally,  this  says  that  if  P is  true,  then  when  S is 
finished,  Q will  hold  for  the  values  computed  for  x and  y.  Since  Pascal  has  value  parameters 
rather  than  Euclid’s  const  parameters,  the  Pascal  rules  have  the  additional  restriction  that  the 
value  parameter  c cannot  occur  free  in  Q.  (There  is  no  loss  of  power,  because  f and  g can  include 
c.) 


The  same  f and  g functions--with  actual  parameters  substituted  for  formal  parameters — are 
used  in  the  procedure-call  rule 

R(f(a,  e,  y,  d)/a,  g(a,  e,  y,  d)/y)  ( p(a,  e)  } R. 

This  rule  resembles  the  assignment  axiom;  in  fact,  the  call  rule  is  equivalent  to  the  simultaneous 
assignments 


a :=*  f(a,  e,  y,  d) 
y g(a,  e,  y,  d). 


This  procedure-call  rule  implies  dynamic  scoping  of  the  variable  y,  i.e.,  y is  from  the  calling 
environment.  The  informal  reports  for  both  Euclid  and  Pascal,  however,  specify  Algol-like  static 
scoping.  Were  it  not  for  Euclid’s  scope  restrictions,  our  rule  would  exhibit  the  same  problem. 
Fortunately,  the  Euclid  report  states  [Lampson77,  p.  39],  "If  a routine  [i.e.,  procedure  or  function] 
is  imported  into  a scope  S,  every  identifier  which  it  imports  must  also  be  imported  into  S."  When 
this  is  combined  with  the  prohibition  against  declaring  an  identifier  which  is  the  same  as  an 
identifier  imported  into  the  scope,  it  becomes  impossible  to  write  a program  whose  behavior  is 
dependent  upon  the  choice  of  static  or  dynamic  scoping. 

Another  slight  problem  with  the  above  rule  is  the  failure  to  "and"  the  term  P(a/x,  e/c)  to 
the  left  side  of  the  procedure-call  rule  (as  we  do)  to  discharge  the  premise  of  the  implication 
defining  f and  g. 

In  the  Pascal  rule  initial  values  may  be  considered  part  of  the  functions  f and  g,  which  also 
accomplish  the  still-necessary  renaming  of  variables,  since  f (a,  e,  y,  d)  and  g(a,  e,  y,  d)  serve  as 
the  new  names.  This  form  of  renaming  permits  an  actual  var  parameter  to  appear  in  a value 
parameter. 

The  Euclid  rule  combines  into  a single  rule  the  relationship  between  a procedure  declaration 
and  calls  of  that  procedure.  While  this  may  be  pleasant  theoretically,  an  actual  implementation  in 
a verifier  of  either  the  Euclid  or  Pascal  rules  would  ignore  this  fact  and  require  essentially  the 
same  verifications  regardless.  As  already  noted,  the  key  idea  is  simply  that  each  procedure  is 
verified  once  per  declaration  and  the  conclusion(s)  of  the  rule(s)  or  the  axioms  are  used  for  each 
call.  Finally,  if  the  procedure  is  deterministic,  the  choice  between  the  general  postcondition  Q and 
the  (single-valued)  functions  ♦ and  g is  largely  a matter  of  taste  because  in  general  Q could  he 
simply 


8 


J.  V.  GUTTAG,  J.  J.  HORNING,  R.  L LONDON 


x - «x\  c,  y\  d)  a y - g(x’,  c,  y’,  d). 

In  Pascal  the  determinism  issue  does  not  arise  because  all  procedures  are  deterministic.  In  Euclid, 
on  the  other  hand,  the  ability  to  traverse  levels  of  abstraction  via  modules  makes  it  possible  to 
write  procedures  that  appear  to  be  nondeterministic  at  the  abstract  level. 


Examples  using  the  Euclid  rule 


We  shall  illustrate  our  procedure-call  rule  using  the  example  in  Appendix  2 of  [Hoare73]. 
Consider  the  trivial  procedure,  with  only  one  v gr  parameter,  one  const  parameter,  and  no 
imported  identifiers'* 

procedure  p(vgr  a:integer;  const  b:integer)  - erfi  true;  post  a i 2*b; 
beam  var  c:integer; 
c 2*b; 

if  a > c then  a c end  if 

end. 

Letting  S stand  tor  the  body  of  this  procedure,  we  can  easily  prove 

true  { S } a £ 2*b. 

The  invocation  of  this  procedure  will  (in  general)  change  the  value  of  a in  some  manner  dependent 
on  the  initial  values  of  a and  b (and,  if  present  and  referenced  from  within  S,  on  values  of 
imported  identifiers). 

Now  the  effect  of  any  call  of  p(z,  w)  is  to  change  z such  that  z S 2*w»  using  the 
procedure -call  rule  we  may  validly  conclude  for  any  R that 

true  a (z«s2*w  a R(ze/z))  { p(z,  w)  } R. 

In  particular,  R might  be  merely  z S 2*w  or  R might  involve  variables  other  than  z and  w if  the  call 
p(z,  w)  followed  statements  involving  them.  The  properties  of  a call  of  p are  contained  in  the 
postcondition  a S 2*b,  which  can  be  derived  only  from  the  properties  of  the  body  of  the 
procedure  p. 

The  given  postcondition  is  not  the  only  property  that  can  be  proved  about  p.  For  example, 
the  postcondition  a - min(a\  2*b)  could  be  used,  where  the  prime  denotes  the  initial  value  of  a. 
Hence  we  may  validly  conclude  that 

true  A (za>min(z,  2*w)  a R(ze/z))  { p(z,  w)  ) R. 


As  another  example,  we  define 
3 — : 

Since  it  is  not  possible  in  Euclid  to  declare  a variable  to  be  of  type  integer,  we  should, 
strictly  speaking,  replace  the  type  integer  by,  say,  the  standard  type  signedlnt. 
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procedure  pKvar  n:infeger;  const  k:integer)  - imports  (c  nst  pnteger) 
pro  trim;  nnst  n^n’+k+j-*- 1 ; 
begin  n :=>  n+k+j  + 1 end. 

Clearly  we  have 

x-x’  a P { S } Q, 


i.e., 

n-n’  a true  { n :»  n*k+j+l  } n=n’+k+j  + l. 

To  show 

m-mQ  { pl(m,m)  } m«mg+mg+j  + l, 

we  use  the  procedure-call  rule  to  obtain 

(*)  true  a (m*=m+m+j+l  o m«=mg*mg+j+l)  { pl(m,  m)  } m=mQ+mQ+j+i. 

Since  m-mg  implies  the  left  side  of  (*),  the  consequence  rule  gives  the  desired  result.  Finally,  to 
show 

m*5  a j=3  { pl(m,m)  } m»14, 

we  need  only  show,  in  view  of  the  procedure-call  rule  and  the  rule  of  consequence, 

m»5  a j=3  o true  a (m*-m+m+j+l  =>  m«-14), 
i.e., 

m-5  a j»3  a m*=2*m+3+l  o m*-14. 


Conclusion 


We  have  been  concerned  with  the  procedure  mechanism,  as  a language  feature,  and  its 
associated  proof  rules.  We  believe  the  full  Euclid  proof  rule  covers  the  complete  Euclid  procedure 
mechanism  (with  the  exception  of  the  problem,  discussed  above,  of  returns  from  procedures  in 
which  modules  have  been  instantiated).  This  is  hardly  surprising,  since  Euclid  procedures  were 
designed  to  satisfy  a predetermined  form  of  proof  rule--adaptation  with  certain  constraints.  Still, 
the  mechanism  is  sufficiently  powerful  for  tasks  intended  to  be  programmed  in  Euclid.  Moreover, 
although  constraints  such  as  the  import  lists  were  included  largely  to  aid  verification,  they  were 
justified  by  other  design  considerations  as  well.  We  feel  that  even  if  verification  is  not 
considered,  these  restrictions  make  Euclid  a better  programming  language. 
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Our  experiences  in  using  the  Euclid  proof  rule  to  verify  programs  are  limited.  However, 
successful  use  of  Hoare’s  adaptation  rule  convinces  us  that  our  rule  is  both  practical  and  useful. 
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